June 14,1987


                           GFATIP05.DOC

                        by John B. Holder
                     Senior Software Engineer
                     Marathon Computer Press
           Asst. Sysop on GEnie's MichTron Roundtable


               USING THE EXEC COMMAND IN GFA BASIC

     This is the fifth in a planned series by this author on 
getting the most out of your GFA Basic Investment.  In this Tip 
file we will briefly cover the EXEC command and some of it's 
possibilities and peculiarities.

     There are several possibilities with this command, however I 
will brush on just a few.  With the EXEC command you can either 
load and execute or load and wait for a subsequent execution time.  
Since the upcoming book by GFA Systemtechnik will go into detail 
of how to load a program and execute it on call, I will skip over 
that option.  The immediate load and go is the most common usage 
of the EXEC command so that will be the mode discussed in this doc 
file and in the GFATIP05.BAS and GFATIP51.BAS files.

     1. To simply load a program and execute it from a running 
application we would do something like this:

                    Reserve Fre(0)-Spaceneeded
                    Exec 0,"Your.Prg","",""

     Now you may ask how much is needed?  Well, you must reserve 
enough for the entire program you are loading to fit into a block 
of memory & you must also allow enough room for it's stack and 
data storage area as well.  This is a process of dynamic memory 
allocation for your called program.  So now you might ask, what is 
the point that I start at?  How much do I give it?  Well, once 
again you have to experiment a bit here to find just the right 
amount.  Start out a little higher than you think you need first, 
and then run your basic program and work the reserved memory down 
until you have the minimum required to execute it successfully.  
If you have not allocated enough memory the load and go will fail, 
and the program will not run.  In that case, just allocate more 
memory and try a run again.
     Now once you have successfully accomplished the allocation of 
memory and the execution of your called program, YOU MUST return 
the memory to the memory pool by doing this:

                  Reserve Fre(0)+Spaceneeded-255

     If you do not return the memory, it will be retained by the 
system and will continue to reduce itself if the program is called 
repeatedly.  Not only that, the parent program will not have the 
memory resource following the return of control without the 
restoration function mentioned above.  The GFATIP05.BAS and 
GFATIP51.BAS files will show you how this MUST be done.

2. Other Possibilities:

     If you would like to call a TTP program and pass in a command 
to it you must use the following calling convention:


                      Suppose the command is 
                         ah new.arc *.bas
                          (For ARC.TTP)

                    Command$="ah new.arc *.bas"
                    Command_length=Len(Command$)
                    Command$=Chr$(Command_length)+Command$+Chr$(0)
                    Reserve Fre(0)-Spaceneeded
                    Exec 0,"Your.Prg",Command$,""
                    Reserve Fre(0)+Spaceneeded-255

     That's all there is to it.  Essentially, what we did was 
formulate a command in our mind (it must be a legal one for the 
program you are passing it to), place the command into a string 
variable, find out the length of the string, reconstruct the 
command as this:

  Length of the command, Actual Command, A null Byte for Padding

     Other than that, the format is the same as that which the 
other flavor of EXEC command uses.


3. Peculiarities:

     If you are calling a compiled GFA Basic program from a parent 
interpreted Basic program, many times following the return from 
the child (compiled basic program you called), you will be 
presented with an alert box asking if you would like to continue 
or quit.  This is because the compiled GFA Basic program is 
passing the interpreted program a signal that says "Let's end".  
It is sort of like pressing the Control+Shift+Alternate keys.  
This peculiarity goes away if you compile the program.  In other 
words, if all of your programs are compiled (Parent, and Child), 
then you will not have this problem.  This is not a problem if you 
don't mind having your program interrupted during development.  
     Now you see why I have included a Demo Program written in 
Modula 2 for an example.  This way those of you using Interpreters 
only can run the GFATIP05.BAS file without interruption.  Since 
Modula 2 uses a different exiting sequence, this "Break" does not 
arise.

     To see the Break example run GFATIP51.BAS.  You will see the 
difference as ICON.PRG is a compiled GFA Basic program.  The Icon 
Demo came from the GFA Basic Companion's Source Code Libraries.  
The GFA Basic Companion will be available at a Software Dealer 
near you or directly from MichTron soon.

     I hope this helps many of you out.  If you are interested in 
getting some questions answered on a live basis, why not stop in 
for one of our weekly GFA Basic Conferences on GEnie at 10:00PM  
EST, 7:00PM PST every Saturday.  A lot of GFA Experts and 
Enthusiasts stop by each week.  We'll be looking for you.